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Abstraetf 

introduction. Virtual communities play an important role in innovation. The paper focuses on 
the particular form of collective action in virtual communities underlying as Open Source 
software development projects. 

Method. Building on resource mobilization theory and private-collective innovation, we propose 
a theory of collective action in innovative virtual communities. We identify three communal 
resources (reputation, control over technology and learning opportunities) that appear as a 
byproduct while developing open source software. 

Analysis. Constructs are derived from exiting literature. Empirical data from Freenet, an open 
source software project for peer-to-peer software, illustrates both the levels of involvement and 
the communal resources. 

Results & conclusions. Communal resources are able to solve the collective action dilemma 
for virtual communities. We show that they increase in value for individuals along with their 
involvement in the community. 


CHANGE FONT 


□ i ntroduction 

Virtual communities play an important role in innovation ( Moon & Sproull 2000: Lakhani & von Hi p pel 2003) . This 
paper focuses collective action in virtual communities. The problem of collective action ( Hardin 1982) and its possible 
endogenous solutions in particular, have been suggested by researchers in management ( Cabrera & Cabrera 2002) , 
economics ( Groves & Ledvard 1977) , sociology and law ( Heckathorn 1993: Tilly 1978: Taylor & Singleton 1993) . 
Virtual communities, such as open source software projects, have found exceptional ways of solving the collective 
action problem. We characterize this solution by complementing the theory of private-collective innovation ( von 
Hippel & von Kroqh 2003) with the notion of communal resources in virtual communities and we empirically explore 
the role of communal resources in collective action. Communal resources provide increasing selective incentives to 
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individuals with deeper involvement in the community. 

The private investment model of innovation suggests that innovation will be supported by private investment and that 
private returns can be appropriated from such investments ( Demsetz 1967) . To encourage private investment in 
innovation, society grants innovators limited rights to the innovations they generate through intellectual property law 
mechanisms such as patents, copyrights and trade secrets. These rights assist innovators in obtaining private returns 
from their innovation-related investments ( Liebeskind 1996) . At the same time, the limited monopoly control that 
society grants to innovators under the private investment model and the private profits they reap represent a loss to 
society relative to the free and unrestricted use by all of the knowledge that the innovators have created. However, 
society elects to suffer this social loss in order to increase innovators' incentives to invest in the creation of new 
knowledge. 

Counter to the private investment model, such projects produce software innovations that are public goods 
characterized by non-excludability and non-rivalry. Open source software is usually made publicly accessible and one 
user's application of the software does not diminish any other person's utility derived from the software. Open source 
software is protected by licences that secure the rights of users to download the code, investigate, modify, apply and 
redistribute the software. Thus, the developer both allows and promotes knowledge sharing through the legitimate 
distribution of the software. Therefore, open source software development projects avoid the social loss problem that 
is associated with the restricted access to knowledge of the private investment model ( von Hippel & von Kroqh 2003) . 
As a public good, open source software does not yield the same opportunities developers could obtain by 
appropriating returns from their investment in a product protected by intellectual property rights. Also, as a public 
good, open source software is subject to the problem of free riding, where any potential beneficiary of the software 
has the option to hold back her own development efforts, waiting for someone else to contribute to it. Conventional 
wisdom suggests that for this beneficiary to contribute software code, sufficient incentives must be available 
encouraging contribution and punishing defection ( Olson 1965) . Someone must bear the cost of incentives and 
mechanisms to control and safeguard the programming efforts of the beneficiary. However, free riding is also 
inauspicious to the provision of the public good: this is frequently referred to as the collective action dilemma in the 
literature ( Oliver 1993) . In other words, why should open source software development projects exist at all? 

For several decades, resource mobilization theory has studied the conditions necessary for collective action to happen 
in society. In particular, authors have been interested in characteristics of organizations that provide members with 
sufficient rewards to act collectively (e.g., McCarthy & Zald 1977 ). In this paper, against the backdrop of resource 
mobilization theory, we pose the following research question: What are the sufficient conditions that mobilize 
programmers to contribute freely to the provision of a public good? Two steps are necessary to answer this question: 
first, combining concepts from resource mobilization and a theory of private-collective innovation outlines the 
particular form of collective action at work in virtual communities, particularly the importance of communal resources. 
Second, a case study explores the properties of communal resources in open source software development. A closer 
examination of the 'fertile middle ground where incentives for private investment and collective action can 
coexist' ( von Hi p pel & von Kroqh 2003: 213 ) combined with insights from psychological studies of developers' 
motivations ( Hertel et al. 2003) reveals that open source software development contains process- related rewards 
( Elster 1986) . These rewards, or communal resources, represent a public good of the second order ( Oliver 1980) and 
resolve the collective action dilemma referred to earlier. Communal resources are collectively produced by the project 
and provide individual rewards for developers and, as we show empirically, these rewards increase with the 
developers' involvement in the open source software project. The paper is organized as follows: the next section 
briefly discusses resource mobilization theory and the literature that leads to an understanding of collective action in 
virtual communities. The section Research methods provides an overview of our research methods and introduces the 
case of Freenet . The section Communal resources identifies communal resources and illustrates their properties in 
the case of Freenet. The Discussion concludes the paper by discussing limitations and further implications for 
organizational theory and research. 
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□ Theory 

The theory section outlines the particular form of collective action that takes place in innovative virtual communities. 
Building on resource mobilization theory, we examine a form of private-collective innovation and focus on the 
organizational conditions that mobilize contributors to open source software projects. There exist many legitimate 
and important ways of studying collective action in the open source software movement, ranging from the new social 
movement theories' analysis of political and cultural aspects of the hacker communities (see Buechler 1995 for a 
review), to rational choice theories' analysis of cost and benefits of individual developers' participation (see Ostrom 
1998 for a review and extension). However, our interest in this paper was generated mainly from Lerner and Tirole's 
observations of the irrational, voluntary aspects of the public good production and the intriguing puzzle they 
formulate. Beyond the individual interest and motivations of developers to contribute to the public good, open source 
software projects, such as the Linux project ( Moon & Sproull 2000 ) and the Apache project ( Lakhani & von Hippel 
2003 ), are also social movements that mobilize resources for this production and within a rational choice and 
instrumentalist framework of analysis these projects derive their own status and deserve further examination. 

Developed in opposition to a Durkheimian view of collective action, which is described as the result of dark irrational 
passions of movement members and the breakdown of society's normative control over individuals, resource 
mobilization theory emphasized the instrumental motivations of groups forming social movements. Whereas 
breakdown theories capture the unrest and mal-integration behind non-routine collective action such as riots and 
rebellion, resource mobilization theory best explains routine collective action such as rallies and protests ( Piven & 
Cloward 1992: Useem 1998) . The resource mobilization perspective argues that organization underlines successful 
collective action projects ( Tilly 1978) , including the professionalisation of such organizations, the career patterns of 
social movement personnel and the emerging social movement industries ( McAdam et al. 1988) . According to a 
review by Baron and Hannan ( 1994) . until the synthesizing essay by McCarthy and Zald ( 1977 ), the contributions to 
resource mobilization had been rather scattered and transient, competing for attention with studies that emphasized 
grievances, frustration, beliefs and collectivity of individual actors (see also McCarthy & Zald 1973) . The elegant 
solution for explaining collective action proposed by McCarthy and Zald (1977) was to look beyond theories and 
empirical work on the social psychology of grievance. In their project, the motives individual contributors might or 
might not have for contributing to the public good succumb to the relative importance of the means by which 
collective action is organized ( McCarthy & Zald 1977: see Oliver 1993 for an extensive review). In the instrumentalist 
view of collective action and the resource mobilization framework of analysis, the creation and deployment of 
selective incentives for contributors to allocate sufficient resources is essential to the success of collective action 
projects (e.g., Friedman & McAdam 1992: Oliver 1980) L However, selective incentives, as Mancur Olson ( 1965 ) 
postulated them, cannot explain collective action, since selective incentives represent a public good as well and 
somebody needs to pay for them in the public's interest ( Oliver 1980: 1993) . 

Open source software development can be characterized as routine collective action, as it is non-violent and not 
aimed at challenging established order or overturning normative control in society. However, open source software 
development deviates from collective action usually analysed in the resource mobilization theory in four ways, which 
shed new light on the role of selective incentives. First, knowledge is both a resource for the project and its goal, 
second, the development process represents the central activity over a long period of time, third, goal directed 
recruiting is largely absent and finally, no measures are taken to prevent free-riding on the public good. First, 
McCarthy and Zald's ( 1977) concept of the resources to be aggregated by social movement organizations covers 
money and labour (p. 1216), as well as time (p. 1227). In their reasoning, social movement industries thrive under 
conditions of resource abundance in society, provided that the general level of disposable income rises, as does the 
shift in control over work schedules from upper echelons of managers to lower level employees in firms. In their 
work, they put no additional constraint on the type of resources the organization need in order to survive (p. 1226). 
In order to meaningfully conduct an analysis of the open source software phenomenon, an additional resource must 
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be added to this framework: knowledge. It is a well-known fact among writers in the resource mobilization tradition 
that social movements create knowledge as a by-product of their activities and thereby generate considerable value 
for society (e.g., Eyerman & |amison 1991 : Flora & Flora 1993: Herman et al. 1993: I ndyk & Rier 1993: Myers 1994 ) 
However, resource mobilization theory, thus far, has not considered collective action that has the production of 
knowledge as the primary organization goal, which is the case for a Free software project (software code) (see von 
Hippel & von Kroqh 2003) . For example, a project that develops software for protection of privacy when sharing 
information over the Internet needs programmers who can bring in specialized knowledge in cryptography. This 
knowledge is probably a rare resource held by only few firms, research institutions, universities, or individuals. 
Therefore, an additional constraint is introduced in the analysis of open source software projects. Not only do these 
compete for time, money, or labour in the social movement industry and sector, provided they have the production of 
knowledge and innovation as their ultimate goal, but also they engage in intense competition for the best knowledge 
and the most talented. De facto, many contributors to open source software projects have regular jobs at commercial 
software firms ( Gosh et al. 2002) and they spend part of either their work or leisure time on developing code for 
these projects. Moreover, if knowledge is a resource on which projects compete, not all contributions are likely to 
further the project's goal of innovating-. As a consequence, the development process assumes central importance 
within collective action. Certain projects (movements), such as Linux, can exist for ten years and more without the 
full functionality of the software being reached. When the goal of the collective action is the production of knowledge, 
the way to reach this goal is part of the goal and the role and character of selective incentives may change. 

In the resource mobilization theory individuals are seen as rational actors who engage in instrumental actions and 
who use organizations to secure resources and foster mobilization ( McCarthy & Zald 1977) . The resource mobilization 
literature has placed a great deal of emphasis on the importance of incentives for joining a movement, cost reduction 
mechanisms for making contributions and career benefits of such behaviour ( McCarthy & Zald 1977: Oberschall 
1973 ). Recruiting and properly motivating participants in a successful collective action project, in order to increase 
the attractiveness of contributing, assumes central importance. With respect to successfully recruiting contributors to 
a collective action task, especially where information about the movement is scarcely distributed among potential 
participants, many writers predict that both the specification of project goals and the nature of recruiting efforts 
should matter a great deal ( Benford 1993: McPhail & Miller 1973: Snow & Benford 1992: Snow et al. 1980) . Thus, 
direct and stable social relationships between recruiters and potential participants are important, so that recruiters 
will have more information about individual motivations and thus be more effective in defining a rewarding goal 
( Oliver & Marwell 1988: Taylor & Singleton 1993) -. 

Because open source projects need knowledgeable developers one would expect that they would engage in precise 
goal formulation and active recruiting. However, successful open source software projects do not appear to follow any 
of the guidelines for successful collective action projects just described. With respect to project recruitment, goal 
statements provided by successful open source software projects vary from technical and narrow to ideological and 
broad and from precise to vague and emergent. Further, such projects typically engage in no active recruiting beyond 
simply posting their intended goals and access address on a general public Website customarily used for this purpose. 
For example, a Freshmeat.net link points to Gnofract 4D site, where the ' Help wanted ' link leads to: 

Please consider contributing to Gnofract 4D. If you aren't a programmer, you can still contribute by 
reporting bugs, writing formulas or coloring methods, creating gradients, or just by posting your 
images to the User Gallery to inspire others. 

Further, such projects typically engage in no active recruiting beyond simply posting their intended goals and access 
address on a general public Website customarily used for this purpose (for examples, see Freshmeat.net). However, 
potential participants can access information about the project by searching the Internet. In open source software 
projects most communication is through the Internet, people rarely meet face-to-face. Some people participate under 
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pseudonyms concealing their real identity, thereby obscuring their interests to the entrepreneur. Even under these 
seemingly adverse conditions, projects such as Linux or Apache have shown that they can be successful in attracting 
large groups, in some cases thousands, of contributors. 

Finally, it is interesting to note that these projects seem to expend no directed effort to encourage one to contribute 
rather than be a free rider. Anyone is free to download code or to seek help from project Websites and no apparent 
form of moral pressure is applied to make a compensating contribution ( Lakhani & von Hi p pel 2003 ). Deviating from 
existing theory, what can explain this type of collective action? A lead can be found in John Elster's ( 1986) work. He 
observed that the instrumentalist ideas of collective action embedded in such theories as resource mobilization did 
not put enough emphasis on the rewards ensuing from process- related aspects of collective action. Elster remarks: 

... cooperation reflects a transformation of individual psychology so as to include the feeling of 
solidarity, altruism, fairness and the like. Collective action ceases to become a prisoner's dilemma 
because members cease to regard participation as costly: It becomes a benefit in itself, over and 
above the public good it is intended to produce. ( 1986: 132) 

Recent developments in economic theory support Elster's conjecture. Thus, Rabin ( 1993 ) and Fehr and Schmidt 
( 2000 ) have shown that a game, which in material payoffs constitutes a Prisoner's Dilemma, can be transformed into 
a coordination game in which cooperation is also an equilibrium outcome if pecuniary motivations and social 
motivations are taken into account. Beyond theoretical and laboratory- based work, Elster's conjecture did not receive 
much attention in field studies of resource mobilization. However, his work has important ramifications for empirical 
studies: individuals are expected to join collective action for rewards, other than that promised by the movement's 
end goal. In other words, there should be private rewards apart from and before the end goal to those that contribute 
to open source software projects, which should be considerably stronger than those available to free riders-. This 
implies that the development process may be just as important as the (envisioned) final product. For example, 
GNU/Linux has evolved since 1991 and its contributors seem to be rewarded quickly for their contributions. 

The notion of communal resources points to the value created by social relations and norms ( Taylor & Sinqieton 
1993 : von Kroqh 2002) when groups are facing transaction costs that could prevent their effective coordination. 
Communal resources take the role of a public good of second order (i.e., represent the selective incentives necessary 
to enable collective action) in that they provide private benefits to individuals who contribute to the collectively 
accessible public good. Researchers on virtual communities know well that enabling conditions include both 
communication infrastructure ( Moon & Sproull 2000) and social factors such as trust ( jarvenpaa & Leidner 1998 ) 

In line with Elster's conjecture, we propose the following: 

PI: The production process of knowledge in an open source software project has, as a by- 
product, communal resources that reward its contributors. 

The empirical phenomenon of open source software development represents a form of collective action where the 
second order public good emerges from the production process of the original public good (here software). In this 
constellation the 'collective action dilemma' that Pamela Oliver ( Oliver 1993: 274) ascribed to Olson's work 
disappears. The characteristics and accessibility of the communal resources are the sufficient, organizational 
conditions that mobilize contributors to the public good produced in virtual communities. Based on our proposition, 
we empirically identify and explore the properties of the communal resources in the case of Freenet, but first we turn 
to the research method and introduce the case. 

□ Research methods 
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In this section we present the method used to study communai resources in the open source software setting. We 
decided to use a case study approach ( Yin 1994: 30: Hartiey 1995: McPhee 1995 ). which is, first, especiaiiy 
appropriate in new topic areas and, secondiy, aiiows us to understand the dynamics present within this setting 
( Eisenhardt 1989: 534) . The purpose of our case study is to investigate communai resources buiit during the 
deveiopment process and rewarding contributors to an open source software project. We have decided to study the 
case of Freenet, an extraordinary open source software project in regard to initiation of the project; how it works, a 
radicai innovation in peer-to-peer software; and considering the newness of the project as wiii be outiined in more 
detaii beiow. The case study expiores our proposition regarding the sufficient conditions for routine coiiective action 
to happen in the novei setting of open source software deveiopment. In this research we combined various methods 
of data coiiection such as interviews, archives, observations of maiiings iists and committed source codes. Quaiitative 
and quantitative data both compiement the insights into the functioning of the Freenet project. In the following we 
first introduce Freenet and then we outline the research design in more detail. 

EH The case of Freenet 

Freenet is software that allows the publishing and obtaining of information through the Internet without the possibility 
of censorship, i.e., the network is completely decentralized and publishers as well as consumers remain anonymous. 
It is a peer-to-peer network which can be used for publishing Websites, communicating through message boards, as 
well as for content distribution. It resembles an anonymous Internet within the Internet. Ian Clarke started the 
Freenet project as a fourth year computer science student. Fie defined the overall goals of Freenet as follows ( Clarke 
1999 ): 

• The network should have no centralized control or administration. 

• It should be virtually impossible to forcibly remove a piece of information from the network. 

• Both authors and readers of information should remain anonymous if they wish to do so. 

• Information will be distributed throughout the network in such a way that it is difficult to determine where the 
information is being stored. 

• Availability of information should increase in proportion to the demand for that information thus preventing the 
Slashdot effect-. Information moves from parts of the Internet where it is in low demand to areas where 
demand is greater. 

Freenet was first released in April 2000. Since then, the Freenet software has been downloaded more than 1,400,000 
times. This shows the significant public interest in this software, which also possibly triggered the interest of many 
potential new developers to the project. When the first public release of Freenet (0.1 Beta) was made, this resulted in 
a steep increase in source code contributions and sparked the interest and entry of new developers into the project. 
Collective action in Freenet includes the discussions on the development mailing list that accompanies the production 
of the software code. On average the Freenet project consisted of 45 (standard deviation = 21) active participants a 
week. This number was achieved around the first public release date of the project and after that it remained fairly 
stable. In 2000, 356 individuals participated in the main Freenet developer discussion list, generating 11,210 e-mail 
messages in 1,714 message threads. 

The case of Freenet represents an extraordinary open source software project which helps us to understand our 
process of interest, i.e., identifying communal resources that are able to solve the collective action dilemma in virtual 
communities. Typically extreme situations and extraordinary types of cases in which the process of interest is 
'transparently observable' ( Eisenhardt 1989: 537 ) are chosen. Freenet has been selected for three reasons in our 
research. First, the development of Freenet hinges on knowledge of cryptography, which is considered a rare 
resource among experts on software development. It pursues the ambitious goal of creating new knowledge rather 
than improving already existing software. In contrast to Linux, Freenet was launched not on the basis of workable 


http : //inf ormationr . net/ir/ 13-1 /paperS 3 2 .html 


4/13/2009 


Page 7 of 24 


Communal resources in open source software development 

code written by an entrepreneur ( Lerner & Tirole 2000) . but rather theory driven by the master thesis of its founder 
Ian Ciarke, outiining the theoreticai principies of anonymous peer-to-peer computing ( Ciarke 1999) . Second, Freenet 
symboiizes a radicai innovation of peer-to-peer software— ( Boehm 2000: Oram 2000 ). which bears increased cost of 
contributing. Freenet has no tempiate of software architecture avaiiabie, such as Unix for Linux ( Wavner 2000) . 
Hence, it can be reasoned that those invoived in the project wouid not have an easy understanding and access to the 
technoiogy. Freenet contributors do not know in advance what to expect of their finai product. Therefore, the cost of 
contributing shouid be considerabiy higher than for projects where tempiates and architectures are avaiiabie (see 
Waterson et ai. 1997 ). Third, Freenet is young in comparison to Linux for exampie, which has been in operation since 
1991. This gives Freenet a 'iiabiiity of newness': the project must compete for knowiedgeabie deveiopers with other 
estabiished projects that have routines avaiiabie for resource mobiiization. This might decrease the iikeiihood of the 
project's survivai compared to that of existing projects ( McCarthy & Zaid 1977) . 

I I Research design 

Data were coiiected for the year 2000, the first year of Freenet deveiopment. The first year is particuiariy important 
for coiiective action as communai resources are buiit up and contributors need to be attracted. This year invoived the 
mobiiization of twenty-six deveiopers to a totai of thirty. Given a fairiy stabie group of deveiopers, it can be reasoned 
that the foiiowing years' data wouid not provide much additionai insight regarding mobiiization of deveiopers. Freenet 
in its first year of existence symboiizes a criticai piiot case with respect to studying our proposition ( Giaser & Strauss 
1967 : Stake 1995: Strauss & Corbin 1990: Yin 1994 ). Combining muitipie data coiiection methods we used expert 
interviews, maiiing iists, source code and archives in our case study research, which wiii be outiined in the foiiowing. 

We started our case study with in-depth interviews and a questionnaire. First, we identified thirteen Freenet core 
deveiopers on the project's homepage and conducted teiephone interviews. The interviews of one to two hours each 
were carried out in the period of October, 2000 to January, 2001 and March to May, 2001 in three rounds. They 
foiiowed semi-structured interview guideiines inciuding topics such as deveioper background information, overaii 
structure of the project, reason for joining and working on the project, rewards, speciaiization and particuiar 
chaiienges in the project. Aii interviews were recorded and transcribed to faciiitate data anaiysis. To obtain further 
insights on communai resources we conducted an additionai survey sending a questionnaire eiectronicaiiy to 
participants in the project in May 2003. 

Second, we anaiysed the contributors' pubiic e-maii conversations gathered in Freenet's maiiing iists. Focusing on 
contributions to the technicai deveiopment of Freenet, we coiiected e-maii data from the 'deveiopment' iist where 
contributors discuss themes regarding the next reiease of Freenet on the Internet, its design, upcoming architecture 
and other technicai aspects. We gathered those messages in a database inciuding contributor identity, date and time 
of posting a message, maiis responding to the message and maii content for the period January 1 - December 26 
2000, on a month- by- month basis. The database consisted of approximateiy 12,000 singie e-maii messages from 356 
unique participants. However, no attempt was made to extend the anaiysis to measure the number of iurkers on this 
iist^. 

In the third step, we anaiysed the committed source code within the Concurrent Versions System (CVS). CVS is a 
pubiic version controi tooi that synchronizes work and keeps track of changes in the source code performed by 
deveiopers working on the same fiie. The CVS archives its version-controi information in a directory hierarchy on a 
centrai server, caiied the Repository, which is separate from the user's working directory. The repository aiiows fiies 
to be added or removed easiiy, or for information about a set of fiies to be sought. The CVS aiso archives the 
deveiopers' comments documenting their work. Whiie source code and comments are pubiiciy avaiiabie, oniy a 
iimited number of about thirty core deveiopers are abie to commit source code to the CVS in Freenet. We found that 
source code commits represented a cruciai data pooi, since project progress was tracked by the progress of source 
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code modifications. Data coiiection in the period January 1 - December 26 2000, consisted of 1,244 source code 
commits from the thirty deveiopers. Exciuding the initiai revisions of code a totai of 54,000 iines of software code was 
added. 

Fourth, we compieted our case anaiyses by taking into account pubiiciy avaiiabie documents reiated to Open Source 
in generai and to the project in particuiar. We studied the Freenet project Web pages (e.g., the Frequentiy Asked 
Questions), Ian Ciarke's master thesis ( 1999) , journais on peer-to-peer software and interviews with the core 
deveiopers-, a working paper describing the Freenet technoiogy ( Ciarke et ai. 2000) and a presentation on resuits of 
a simuiation of the software ( Flonq 2001) . We contacted the Freenet deveiopers by e-maii in case of any queries, 
ambiguity, or iack of data. In the next section we wiii outiine how we proceeded with data anaiysis regarding rewards 
for those who contribute this substantiai amount of deveiopment work to Freenet. 

□ Communal resources 

Consistent with resource mobiiization theory, it is oniy possibie to mobiiize hackers to contribute to an Open Source 
project if the individuai cost-benefit anaiysis reveais outweighing benefits. We propose the characteristics of and 
access to three distinct rewards, or communai resources. Communai resources do not exist prior to the coiiective 
action and they are not used in a recruitment process or somehow targeted to the individuai. Rather, they are 
produced during the deveiopment process and are accessibie under certain conditions to seif-aiiocating, individuai 
programmers. The communai resources share, aiong with Oison's concept of seiective incentives ( 1965) , the function 
of mobiiizing individuais, where both represent the benefit-side of the individuai rationaie for participating in a 
coiiective action project. Flowever, opposed to the seiective incentives, communai resources are not provided by a 
particuiar person or institution that carries the cost ( Oiiver 1993) . Flere, this probiem does not arise, since the 
communai resources emerge from the production process of the open source software. A programmer in Freenet 
chooses, or aspires to a particuiar ievei of invoivement in the project. Invoivement, in turn, is iinked to the extent to 
which the communai resource is accessibie. In other words, the benefit that can be reaped from access to the 
communai resource increases with invoivement. 

In a first round of anaiysis, we searched for themes in the interviews that wouid reveai specific communai resources 
for the deveiopers. We were iooking broadiy for statements touching upon what peopie experienced as deveiopers in 
Freenet and why they contributed to the project. This form of anaiysis is very simiiar to what Bariey ( 1990 ) caiied 
systematization of topics emerging from his observations of radioiogy departments. We found topics that couid be 
grouped in three communai resources: reputation, controi over technoiogy and iearning opportunities. Reputation and 
controi over technoiogy in a coiiective deveiopment effort cannot exist before the community does and iearning 
opportunities open with the observation of work or the interaction of the programmers. Aii three communai resources 
are features of the deveiopment process-. In subsequent iterations of anaiysis we sought to make the three 
constructs operationai. 

I I I nvolvement 

For the anaiysis of Freenet we distinguished the participant's ievei of invoivement into three distinct categories: 
iurkers, contributors and deveiopers. 

Lurkers eavesdrop on maiiing or discussion iists without posting ( Nonnecke & Preece 2000) . This group heips to 
promote standards by using the software, to spread reputation and represents a pooi of potentiai new deveiopers, 
since neariy aii deveiopers started out by simpiy reading the maiiing iists and trying out the software ( von Krogh et 
ai. 2003 ). As mentioned in the next section, we couid coiiect no data on iurkers, aithough some interviewees reveaied 
they had iurked for an extended period of time before becoming deveiopers. 
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The second group, the (regular) contributors, constitutes the largest visible group of affiliates to the project. They 
either contribute code through a 'gatekeeper' (developer) who has CVS write access and evaluates the submission, or 
they participate in the discussions. The breadth of involvement for contributors is large. At one extreme, a contributor 
may make exorbitant demands for features (few might even value a contribution being a mere request), where at the 
sophisticated end a contributor may be involved in technical discussions and regularly submit useful patches-. 

Members of the third group, developers, are defined by the permission to modify the Freenet source code in the code 
repository. The developers take on the vast majority of coding, plan the version releases and decide on the inclusion 
of features or any issues determining the overall direction of the development. Access is granted to a relatively small 
circle of skilled programmers who have earned the trust of other developers through their contributions and effort 
given to the project ( von Kroqh et al. 2003 ). In the case of Freenet, thirty developers were granted developer status 
during the data collection period. 

In a project interview, Freenet founder Ian Clarke stated that involvement is generally associated with increased 
technical skills, merit and a sense of responsibility. It should be noted that within the contributor and developer 
category, the level of involvement varies significantly. Within these groups involvement can be measured through, for 
example, the number of sent e-mails and the number of code contributions. Among the thirty developers we found 
some who were particularly active, e.g., the top four developers produced 50% of all e-mail traffic. 

In the following, we argue that the level of involvement influences the individual access to the communal resources. 
Table 1 synthesizes the types of rewards corresponding to the level of involvement and the communal resources. 


Level of 1 nvolvement 

Communal Resource 

Reputation 

Control over technology 

Learning Opportunities 

Lurker 

No 

No 

Passive 

Contributor 

Low 

Limited 

Passive Si Feedback 

Developer 

High 

Extensive 

Passive Si Quality Feedback 


Table 1: Summary of the findings for involvement and communal resources 


Reputation 

Reputation is attributed to a person and develops over time. It reflects other observers' judgments and does not 
imply a value statement. Reputation can be positive or negative and it can improve or deteriorate. We limit our 
analysis of the data to the establishment of a good reputation in Freenet. Of course, there exist reputation losses and 
various forms of sanctions in Open Source communities that are not considered here (for more on this, see O'Mahony 
2003 ). Reputation can only exist vis-a-vis an audience. Since open source projects consist of experts in computer 
programming and the daily work on coding and the technical discussions for a particular project hardly ever resonate 
outside the project, it makes sense to distinguish the audience inside from the one outside the project. Thus, 
reputation is created within an Open Source project and may, under certain conditions, spill over to a wider public 
outside. We distinguish the audiences outside and inside the project and present reputation within the project as a 
communal resource by showing a relationship to the level of involvement in the project. 

Using a labour market argument, Lerner and Tirole ( 2000 ) and Lee et al. ( 2003) suggest that developers who build a 
strong reputation in the Open Source projects would enhance their human capital and so would raise their value to a 
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potential employer. Although intriguing, the interviews we conducted with the developers of Freenet did not confirm 
that they contributed in order to raise their value in the labour market for software engineers. For example, a 
developer, who calls himself 'Mr. Bad', used fictitious identities to conceal his real identity and developers often 
obscure their affiliations with software firms. Rather, it seems the direct effect of reputation among peer developers 
was important to Freenet developers, which is consistent with assertions in the literature ( Flimanen 2001; Lerner & 
Tirole 2000: Raymond 1999 : Risan 2001) . As core-developer Scott Miller put it: 

'If I am writing a program why not release it as Open Source? It doesn't cost me anything and, you 
know, it might be good for my reputation, it might get me involved in other things. And I think that's 
how I got started programming in it.' 

Or as Oskar Sandberg, also a core developer, admitted: 

'Yeah, in a way. I like to, I like to do something extra, I try to make my code nice or make the other 
people I work with like it (laughs). And yeah, of course it's always good to hear nice things about your 
work and such things. It would be harder to work if I wouldn't get any further positive feedback, of 
course.' 

However, the global hacker community celebrates its own stars such as Eric Raymond, Bruce Perens, Ian Clarke and 
Linus Torvalds. These are people who have made major contributions in terms of software code and hence based on 
their merits attained a strong reputation. Even further away from the hacker culture, there exist examples of hackers 
who attracted a wider public attention through media coverage such as books for the non- hacker (e.g.. Moody 2001) , 
the foremost example being Linus Torvalds ( Torvalds & Diamond 2001) . As these examples are very rare, worldwide 
fame cannot be expected from an involvement in an Open Source community. What can be expected are like-minded 
hackers and experts in their fields of programming who scrutinize new code and evaluate its functioning and 
consequently the achievement of its author. Similar to written text, the criteria for evaluation of software code seem 
unlimited and hinge on personal preferences ranging from viewing code as a simple tool to a form of art (e.g., Knuth 
1969 ). 

In a technical community, which judges people on merits rather than personality, a programmer's reputation is 
mainly built over time through excellence in coding ( Kohanski 2000: Raymond 1999 ). In Freenet, although code 
patches were sent to core-developers by various contributors (before they received CVS access or as a singular 
contribution), the core-developer had what we would call a fingerprint advantage. The code was committed to the 
CVS identifying the developer who entered it into the CVS. This person was not necessarily, although most of the 
time was, identical to the author. At this point the code was open to scrutiny from the public. Our interviews revealed 
that the hackers typically found code (of others and themselves) to be elegant if it could perform a complex or 
difficult task yet required limited computer processing. If the code was small in terms of lines of code, but still 
important for the functionality of the overall Freenet software (see Kohanski 2000) , the core-developer had a unique 
possibility to build a reputation within the Freenet community among the other project participants and potentially 
also outside the Freenet project environment. In Freenet, this type of reputation building was open only to the 
developers with CVS writing access. 

Another way to contribute was to participate in development discussions. The mailing lists were public and anyone 
could read and comment. This form of contribution to the project did not directly require coding skills, though for 
competent participation (incompetent comments tend to be ignored), a certain level of technical expertise and sound 
knowledge of the state of the project was indispensable. Useful comments included references to various sources of 
information or new ideas on a problem discussed. As valuable as these contributions may be, they were 'only' written 
speech and not source code. 
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We measured reputation as the number of neutral references and explicit praise given to a person within the 
community. A neutral reference to a person means the mention of the person's name in the mail discussion. The vast 
majority of references involved neutral or positive assessment of the person's work. We counted all references to 
core-developers in the developer mailing list of Freenet for the year 2000, except those with frequent names (where 
potential confusion compromised the quality of the analysis) and excluded four outliers (Ian Clarke, Oskar Sandberg, 
Brandon Wiley and Scott Miller), each of whom wrote, on average, three times more mails than the next frequent 
discussant. The nineteen core-developers were referenced on average 93.9 times, with the median being 80 and the 
standard deviation a high 87.5. A randomly chosen sample of equal size out of the 356 contributors without CVS 
access revealed an average of 3.4 references with the median being 0 and the standard deviation 8.3. These 
differences in references reflect the number of mails sent to the list and hence reflect how well known core- 
developers were compared to regular contributors. On average, a core-developer sent 132 mails to the mailing list, 
whereas the average from our contributor sample was 11.2. In the analysis on explicit statements of praise, only one 
in twenty lauds was addressed to a regular contributor, whereas the other nineteen were directed to core-developers. 
For example, in August 2000 Oskar Sandberg wrote: 

'There are two separate projects to write Freenet nodes in C and C-f-f. One is getting along only 

because of Adam's noble and excellent work' 

Or on a more humorous note a contributor by the name of Flute Gardener wrote in October 2000: 

'Oskar [Sandberg] is better than god and eminem. Neither god nor eminem write Freenet code! 

Although it would be kinda cool if great code would inexplicably appear in the CVS.' 

Clearly, reputation was only accessible for the core developers, who were mentioned regularly. Most contributors 
were referenced far less frequently. Within the large group of contributors the number of mails sent to the discussion 
list ranged from 1 to 128. A Wilcoxon- Mann- Whitney rank sum test rejected with 99% confidence that the references 
of both samples (core developers and contributors) stem from an identical distribution. Lurkers cannot have a 
reputation, for they never appeared publicly. Reputation is not automatic and can also be understood as a reputation 
opportunity, in this context. This analysis does not explain the causes of reputation, but the association suggests that 
reputation increases for the same reasons as involvement increases. 

P2: The individual benefits from reputation increase with involvement in the community. 

Control over technology 

The second communal resource we identified was control over technology. Developers are able to control what and 
how the software is going to work, the compatibility or lack of compatibility with other software and to a certain 
extent who is able to use the software through various means. As mentioned only thirty developers could commit the 
code that eventually comprises the software innovation. Furthermore, code developed by non-developers was 
reviewed and a developer decided on its potential inclusion in the source code repository. By submitting the source 
code themselves, the developers maintained a tight control over the source code and, therefore, the functionality of 
the Freenet technology—. 

We found, for example, that some developers had strong ideological interests associated with Freenet, particularly 
regarding anonymity. An important technical discussion continued among developers and contributors for weeks 
regarding the search for files in Freenet. A file search function that would make the location of information easier for 
Freenet users could at the same time compromise anonymity of the sender and receiver of information and was 
deemed against the Freenet design goals by some developers. While this discussion generated considerable 
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discussion voiume, the deveiopers decided not to inciude any software fiies that wouid compromise the anonymity of 
the users. In this sense, priviieged access to the controi of technoiogy aiiowed deveiopers better opportunities to 
reaiize their interests than non-deveiopers in the project. 

If anybody could impact on the technology developed, it seems likely that the utility people derive from belonging to 
the developer group would diminish rapidly. Imagine a malevolent developer intentionally committing code to the 
CVS, which caused the software to malfunction. In this case, the returns on the developers' personal investment in 
coordination, code writing, discussion, code reviewing, debugging and so forth would diminish rapidly. Hence, control 
over technology afforded to developers whose work one judges as valuable, secures all developers' future rewards 
associated with the development of the technology. Of course, this communal resource would not hinder an existing 
developer in committing code that would break down the technology. However, in Freenet, for a contributor to 
become a developer with CVS access required on average 23.4 messages before he was given access. These 
messages contained highly technical content such as suggestions to fix a bug in the software, a code patch, or a 
software- related commentary or review. This relatively lengthy and costly process of joining the project made it 
easier for the existing developers to identify a capable new developer and any adverse action, once privileged access 
had been given, would have caused a negative reputation beyond the project within the hacker community at large 
( Raymond 1999 ). 

Being able to control what functionality was worked on in order to satisfy one's own personal needs proved to be a 
communal resource in order to mobilize contributions to the Freenet project. This interview quotation from a 
developer illustrates this point: 

'My main interest, at the time, was getting my magazine published on Freenet. There weren't really 
tools for doing a full Web site and I spent some time working on making a tool for that, working on 
fixing the client interfaces and in some marginal areas of the [core parts], to make it work, so my 
magazine could get published.' (Mr. Bad) 

The quotation also shows that developers controlled what was being worked on in the technology through the self- 
appointment of tasks. This seems typical for open source projects ( Schoonhoven 2003) as, unlike in a software firm, 
contributors and developers in such projects cannot be assigned to certain tasks they are not willing to implement. In 
this way, they have an inherent degree of influence over which parts of the software are expanded and improved. 

Another dimension of control over technology is concerned with agenda setting. Cohen et al. ( 1972) argue that 
participants in an organization are only able to make a restricted number of choices within a certain time frame. 
Therefore, 'attention patterns' within the project matter, implicitly deciding on what choices are discussed and made. 
In Freenet, agenda setting can be measured through the percentage of initiated threads on the development mailing 
listxm By starting a new series of e-mails on a certain topic, a developer or contributor was able to define the topic to 
be discussed within the project. In-depth analysis of single threads revealed that some tended to change the topic 
during their existence and the number of threads might not exactly represent the number of topics discussed. 
However, it is still an acceptable indicator of 'what went on' in the project. We found that each developer started 34.9 
(standard deviation: 64.65) threads, whereas each of the contributors only began 4.81 (standard deviation: 3.92) 
threads on average. Developers were more active in setting the agenda within the project, therefore shaping the 
attention patterns Cohen et al. ( 1972) discussed. Developers were also able to add new and modify existing items on 
the ToDo list, a text file describing potential next steps that are considered a priority by the project. Newcomer 
contributors often used this list to get a sense of what was important in the project and, therefore, it shaped the 
general direction of the software development. 

As the developers decided on how the software was released during the various stages of development, they could 
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control how the software was used and by whom. Analysing the threads in e-mails, two issues we found to be 
important by their recurring mentions were the release frequency and the release date. A high release frequency 
normally allows the public to test recent source code additions and the developers, thereby, can get faster feedback 
on new functionality or problems with the new version ( Raymond 1999) . However, each release will be less tested 
and probably, therefore, less stable, as opposed to having fewer but more thoroughly tested releases. Freenet solved 
this problem by infrequently releasing stable versions complemented by daily 'snapshots' (a snapshot refers to an 
automatically packaged software release, derived from the current state of CVS code). 

The importance of release scheduling in the Freenet community is illustrated by the following quotation from a 
contributor: 

'I know that Ian is going to start pushing for a release schedule again now and I'm beginning to fear 
that if we don't indulge him soon he will suffer spontaneous human combustion. Certainly, most of the 
big issues have been weeded out now and I too am somewhat interested in seeing what happens when 
people actually use Freenet.' 

The release dates were also important as they determined which features were included in the next version of 
Freenet as the following e-mail quotation shows: 

'What do people think - release now or wait for persistent connections?' (Ian Clarke) 

The third aspect of release management was the packaging and distribution methods being used for the software. 
Networking software like Freenet, whose proper functioning depends on network externalities, requires a broad user 
base in order to work reliably. Therefore, making pre-packaged software distributions available, which could easily be 
installed by regular users, was crucial to the success of the project. A comment by a contributor expressed the need 
for this: 


'As a Windows user my only beg is that there is a easy way (sic!) for the jabronis to install it that is as 
simple as Gnutella or Shoutcast . The more folks banging away at this the better.' 

Responding to such calls, some developers spent considerable efforts in building software modules that could provide 
easy installation on various computer platforms, thereby enhancing functionality as well as the general distribution of 
Freenet in line with its objectives. In fact, an analysis of the technical characteristics of the software revealed that 
most of the new developers who joined the project in 2000 made their first commit of software to the CVS on this 
functionality ( von Krogh et al. 2003 ). By controlling release frequency, release dates and packaging and distribution 
mechanisms, developers were able to control to a certain extent who could use the software with what level of 
stability when running the software on their computers. 

In sum, we conclude that developers and, to a certain extent, active list contributors (by their e-mail messages) 
through their increasing involvement were rewarded by the communal resource 'control over the technology' through 
the following: direct CVS write access, self appointment of tasks, agenda setting on the discussion list, a ToDo list 
and release management. 

P3: The individual benefits from control over the technology increase with involvement in 
the community. 

Learning opportunities 


http : //inf ormationr . net/ir/ 13-1 /paper3 3 2 .html 


4/13/2009 


Page 14 of 24 


Communal resources in open source software development 

The third communal resource consists of learning opportunities, defined as collectively accessible opportunities for 
learning that each individual faces. These opportunities are represented by access to software source code, to experts 
in a very specialized field, to technical discussions with peers, or to direct feedback to one's own work. The amount 
and the quality of the learning opportunities increase with the individual involvement in the project. 

The literature classifies learning ( Bloom, 1956 : Kratwohlet al. 1964) , evaluates learning ( Biggs & Collis 1982 ) and 
describes how learning may take place (see Atherton 2005 for a broad review; Lave & Wenger 1991 : Reynolds, 
1965 ), but the concern often lies with the individual's learning success. Our data do not tell us whether people 
actually learned in Freenet. Rather, we found conditions and an environment associated with learning at the level of 
the project without which the project would not have continued (to be able to make a contribution to the emerging 
software, people first had to understand the emerging software architecture). These conditions include a general flow 
and exchange of information, feedback and review mechanisms, externalization of knowledge through code and 
recombination, ( Nonaka 1994) and participation ( Lave & Wenger 1991) in the development process. Wenger 
suggested that the emergence of boundaries of a group could be an indicator of the possibilities for collective learning 
through feedback among its participants: 

The local depth these groups... provide inevitably creates boundaries, which are... also a sign of 

learning. But then boundaries themselves become learning opportunities and the richness of boundary 

processes becomes a sign of learning as well. ( Wenger 1998: 256 ) 

In other words, active involvement in the group matters, implying that learning opportunities for those who are 
included in the development process should be higher than for those outside the boundary of the group, or the 
peripheral participants. In the context of Open Source these conditions function as a communal resource and we 
termed them learning opportunities. 

There exists a non-linear relationship between cumulated learning opportunities and involvement which starts at very 
low levels of involvement (lurkers) and peaks at the global maximum with the most highly involved developer in the 
project (in terms of committed lines of code and number of sent e-mails). In reality, involvement represents a 
continuum: it is conceptualized as interest in and commitment towards the project and it was measured for each 
actor by the interaction frequency (mails sent to mailing lists) and coding intensity (lines of code written or code 
modifications to the CVS repository within a certain time). Lurkers are publicly invisible, by definition and represent 
the lowest level of involvement. De-lurking, the first public appearance in the Open Source project, represents a first 
distinction to the second type of actor, the contributor. The second distinction is CVS write-access that distinguishes 
the third group: developers. Our categories follow the idea of looking for boundaries of group membership and 
classify the actors involved in an Open Source project in three somewhat arbitrary but practical levels of involvement. 
For each level of involvement we highlight in this section the applicable learning opportunities. 

Learning opportunities cumulate as involvement increases. An additional learning opportunity can either be of a new 
type or of increased quality, such as more depth of expertise in a conversation or a peer review of the mail message 
or the software code. The quality of a learning opportunity does not refer to the learning taking place, but to the 
quality of access to the source of knowledge in the project. A skilled programmer can learn more as a lurker 
(passively reading through conversations and code) than an incompetent discussion participant can. Nevertheless, 
the latter has an additional opportunity: interaction. We distinguish two classes of learning opportunities: passive and 
interaction- based. Our analysis of e-mails revealed this could be a natural and valid distinction for developers. 
Consider the following excerpt from an e-mail of a contributor: 

I wanted to spit out a very quick introduction to everyone. I just joined the freenet-dev list today and 

I'm very eager to get involved in the project. I think the concept is absolutely brilliant! I am a software 
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developer with about three years of experience in the commercial world writing Java.. for my day to 
day living. My most recent project lasted two years and involved a distributed architecture based on 
RMI with cryptography provided by Sun JCE... Hopefully, similar skills are needed somewhere in the 
FreeNet project. I'll be happy to look through the code and help out where needed, whether it's heads 
down coding, debugging, writing JavaDoc, or authoring whitepapers. Whatever. Until then. I'll shut up 
and just absorb the culture a little bit and get my bearings! 

Here the contributor indicated his knowledge but also the need to passively learn more about the specific tasks where 
his expertise in Java programming could be put to use. He decided to step back and lurk until the appropriate task 
had been found. Our interviews with developers revealed similar approaches. People would lurk and observe the 
project for a while (up to two months) before they announced their presence on the developer list. However, the 
learning opportunities intensified as they joined as contributors. As mentioned above, those twenty-six people we 
observed joining the project demonstrated considerably higher levels of technical activity than the average 
contributor, before they were given access as developers to the CVS. They would suggest technical features, bug 
fixes and give gifts in the form of software patches. They would receive feedback from other developers and 
contributors and change their work and ideas accordingly. Framed in Wenger's ( 1998) concept of group learning, the 
boundary of the developer group created its own learning opportunities for those who joined the project at the level 
of CVS access. 

Interaction, in turn, uses two media, human language (usually English) and computer language (code). Hackers 
hardly ever meet face-to-face and thereby exclude all non-verbal communication except for code. One refers to the 
interaction in conversation and the other to interaction through code. Conversations on mailing lists ranged from 
superficial to very technical. The dominant medium was written (English) language in mailing lists and code was 
rarely copied into an e-mail. The interaction relating to the software code took place on the basis of computer code 
(and did not necessarily require human language, although developers frequently used written statements alongside 
the code to help others understand the meaning of it). Both types of interaction can be understood as feedback 
learning opportunities. Interview data on this peer-review process, as it is sometimes called, suggests feedback was 
strong enough to even induce developers and contributors in part to evaluate their competence (likely intense form of 
learning). Ian Clarke, the founder of the Freenet project, said: 

There's also this intensive continuous peer review process that means that if somebody doesn't have 
the appropriate skills or understanding, they will very quickly be admonished for it. It's this intensive 
instantaneous peer review that makes it much easier for people to self-select. 

Lurkers are by definition invisible to the public eye. If measured solely by their interaction their involvement would be 
zero, but as opposed to anyone not interested in the project, lurkers do get passively involved. They may access all 
publicly available data including the code base and the discussion lists, current and past. These passive learning 
opportunities include vast sources of information and codified knowledge. They are never personalized, however, 
since the lurker does not ask questions. 

The range of possible interactions for contributors was large and, consequently, the learning opportunities differed. A 
simple one-time comment in the discussion may have resonated very little to not at all. A frequent discussant and 
skilled programmer without CVS write access (still contributor and not developer in our classification) enjoyed 
considerably more and better learning opportunities than the one-time contributor. Hence, involvement varied greatly 
among contributors. All contributors faced the passive learning opportunities of the lurkers and in addition, the two 
types of feedback learning opportunities. First, statistically, a discussant could expect a reaction on a mailing list 
posting, as we will see below. Not surprisingly, the reactions differed in quality depending on the nature of the 
discussion and the nature of the question. Consequently, the quality of the learning opportunity varied from low. 
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associated with superficiai discussions, to very high, where the discussion was technicai and the discussants dispiayed 
extraordinary expertise. Thus, the more invoived a contributor got into the depths of technicai discussions, the higher 
was the quaiity (and expertise) of the reactions on his question or input. 

Second, code-based interaction offered another feedback iearning opportunity. Many contributors join an Open 
Source project by fixing bugs or offering software patches as gifts to the project ( Bergquist & Ljungberq 2001 : von 
Kroqh et ai. 2003 ). In Freenet, these patches, without exception, were reviewed by a deveioper with the authority to 
add them to the code base of the project (the CVS) and the possibie review resuits offered numerous iearning 
opportunities for the author. The code was accepted or rejected. If accepted it was sometimes modified by the 
deveioper who appiied the patch. Both options invoived a form of direct feedback for the author's work. The new code 
may have spurred coding in other moduies of the software when adaptation to the new feature was necessary. 
Remember that Freenet, during the period we researched, grew to 54,000 iines of software code. By iearning about 
how the submitted (accepted) patch triggered deveiopment work across the whoie software architecture, in other 
features and moduies, the author couid gain a better understanding of the overaii code. This e-maii interview 
quotation by a deveioper iiiustrates how a new patch may trigger discussions among other community members: 

Direct feedback usuaiiy comes in form of defect reports (ciosing of existing ones or opening of new 
ones!) as well as subsequent discussion on mailing lists, particularly if the patch needs more 
explanation (the resulting explanations then benefit all developers and readers of the mailing lists). 

Again, the quality of these learning opportunities differed mostly due to the nature of the new code. The larger the 
impact of the new code on the existing software, the wider the attention it drew from the contributors and 
developers. This became clear, for example, in the discussion mentioned above regarding search modules in the 
software, which developers and some contributors believed compromise anonymity and hence ran counter to the 
Freenet design goals. 

The relatively small group of thirty developers were the most assiduous coders, the most frequent discussants and in 
general the people who ran the project. Participation in the development list was highly concentrated with four 
individuals, or 1.1% of the population accounting for 50% of the e-mail traffic. All of these four individuals were 
developers with the status of committing code to the CVS. The GINI coefficient for message authorship was 0.89 
confirming this concentration of activity. In addition to the learning opportunities the contributors have access to, the 
developers enjoyed the largest share of attention by the other developers and participants and their work was 
reviewed most frequently. Assuming, like many observers of software development work (e.g., Kohanski 2000: 
Pavlicek 2000) that every line of code written represents a potential software bug and that it needs review and 
testing, it is obvious that the most important authors of code receive the most reviews of their work from which to 
learn. On average there were twenty-four (standard deviation 18) commits a week to the CVS code repository. All 
thirty developers (8.4% of the total community) added code to the project. There was a high degree of concentration 
in the code- writing task with four developers (13%) committing 53% of the code to the CVS repository. The GINI 
coefficient for the code commits was a 0.77 indicating a high degree of concentration in the code commit task. 

A similar pattern appeared in the mailing list conversations. Message threads signified that authors of an e-mail 
brought an important theme of software design to the attention of the project and that this theme sparked further 
discussion, each new e-mail making a reference to the original e-mail. Thread initiation was similarly concentrated 
with ten individuals, 2.8% of the population, accounting for 50% of messages threads initiated. Again, all of these 
were core-developers in the project. The GINI coefficient for thread initiation by participants was 0.80. A high 78% of 
the population attempted to initiate dialogue at least once on the developer list. Of these attempts only twenty- nine 
(10.5%) participants did not receive any reply to their initial posting and did not appear on the developer list again. 
Choosing a particular topic was a way for developers to set the agenda and efficiently access knowledge of 
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developers and contributors. Developers not only received a lot of individual feedback, they could, because of their 
central position in the project, even access the majority opinion and get a feel for what the 'collective feedback' was 
(e.g., interview quotation by Ian Clarke above regarding release date). Amongst themselves, developers sometimes 
worked in small and highly specialized teams on a particular problem or module ( von Krogh et al. 2003 ). This intense 
exchange with other developers offered another high-quality feedback learning opportunity. 

A variety of learning opportunities is available to open source software development project participants at different 
levels of involvement. Together they constitute a communal resource which is produced in the software development 
process and which is open to those who engage in an Open Source project. There are passive and feedback learning 
opportunities that in turn vary in quality. An expert replying to a technical question represents a higher-quality 
learning opportunity than an unqualified comment. The key insight into this communal resource, however, is the 
positive relationship between involvement and learning opportunities, where only interaction can generate direct 
feedback from a large number of contributors (in Freenet's case, more than 356 individual contributors and 
developers). The quality of feedback usually reflects the level of expertise and skill of the programmer regarding the 
project. And this expertise is closely linked with involvement. 

P4: The individual benefits from learning opportunities increase with involvement in the 

community. 

Discussion and conclusions 

While a new phenomenon calls for extensive empirical work, this paper also demonstrates that empirical studies need 
to be guided by theoretical frameworks. We chose resource mobilization theory to guide the inquiry into Freenet, 
investigating conditions that are sufficient to mobilize programmers to contribute freely to the provision of a public 
good. Our exploratory case study showed that the knowledge production process in an open source software project 
itself created several communal resources as a byproduct. These reward contributing individuals for their efforts. In 
Freenet, the communal resources were reputation, control over technology and learning opportunities. Our study has 
general implications for resource mobilization theory, collective action, research on open source software 
development and technological innovation. 

There are two main contributions to resource mobilization theory. First, in our reformulation of Lerner and Tirole's 
question (What are the sufficient conditions that mobilize programmers to contribute freely to the provision of a 
public good?) we employ a resource mobilization framework, identifying the characteristics of and the accessibility to 
three communal resources. Through these, open source software development mobilizes the knowledge, time and 
efforts of individual programmers to produce new and innovative software. Communal resources emerge during the 
production process of this public good as a by-product through the collective interaction of project contributors and 
developers during the development process. But the rewards that they provide are only accessible for the individual 
contributors. This solves the theoretical puzzle of mobilizing 'rational' individuals without the need to assume a sort of 
intrinsic or altruistic motivation, or to reduce motivation to a labour market value argument. 

The concept of communal resources explains the emergence of collective action among rational actors contributing to 
a public good in spite of active and widespread free riding. Based on our analysis, we thus provide some empirical 
grounding for Elster's ( 1986 ) conjecture on process- related rewards. Collectively accessible, but individually 
rewarding, communal resources are also a public good for those with the interest and skills to take advantage of 
them. Therefore, communal resources provide and correspond to Olson's selective incentives. This solves the second 
order public good problem discussed by Oliver ( 1993) . Therefore, open source software development establishes a 
theoretical typology of collective action (see Oliver 1993: 293) . 


http : //inf ormationr . net/ir/ 13-1 /paperS 3 2 .html 


4/13/2009 


Page 1 8 of 24 


Communal resources in open source software development 

This leads to the second contribution to resource mobilization theory: it has been applied to social movements where 
contributions have neither been distinguished nor selected by the movement. However, open source software 
represents a theoretical type of collective action where both the value of the public good and the character of its 
development process require careful selection of available resources, because knowledge is both a resource and a 
goal of the project. Freenet did not expend resources on recruiting contributors. Nevertheless, in the year we studied, 
their number grew to 356 people. Among these individuals, skilled programmers stepped forth and existing 
developers observed their interest, commitment and contributions to the project, before admitting them as 
developers. In this sense, open source software projects produce a public good in an inverted form of collective 
action, through social sampling rather than mass mobilization. 

Further research could elaborate a formal model of collective action in open source and apply it to other situations. 
For example, academic knowledge creation has a number of parallels to open source software development, where 
communal resources such as reputation, may be observed in academia as well (see also Stephan 1996) . A broader 
approach towards communal resources may generate categories of possible communal resources. What other 
determinants of individual rewards from communal resources exist? How exactly do communal resources emerge and 
how do they disintegrate or disappear? Can aspects of this typology of collective action be relevant for voluntary 
action within a firm whose product is knowledge? 

If communal resources can explain collective action in an open source software setting, we may also employ the 
concept to the analysis of competition in the social movement industries called for by McCarthy and Zald ( 1977) . 
Comparative case studies of open source projects could identify perceptions of communal resources held by 
participants across projects. Faster access to, or higher quality communal resources might induce programmers with 
scarce knowledge to join specific projects (or social movement). Communal resource may therefore influence the 
competitive position of social movements. This, in turn, raises questions regarding group composition as a specific 
problem of resource mobilization. In other words, in a competitive environment, how can a project attract the 
necessary knowledge to survive? 

Previous studies in open source software have established measures of group activity in open source projects ( Koch & 
Schneider 2000 ), psychological measures for individual developer motivations ( Hertel et al. 2003 ). specialization of 
developers and their level and type of activity ( von Krogh et al. 2003 ) and users' satisfaction with the software 
product ( Franke & von Hi p pel 2003) . Our research establishes and identifies the constructs of reputation, control over 
technology and learning opportunities as instantiations of communal resources. In the Freenet project we found that 
access to communal resources did increase with a higher level of involvement. Further research can use these 
measures to validate and extend the existence of communal resources across a wider sample of open source software 
and other knowledge based projects. 

Open source software products exist as public goods, whereby the knowledge is available to anyone interested, 
avoiding the social loss problem of innovation seeded and secured by private investments in the private innovation 
model ( von Hippel & von Krogh 2003) . Therefore, societies have incentives to foster innovation through collective 
action as observed in open source software, as a form of the private-collective innovation model. If communal 
resources provide the necessary selective incentives to mobilize individuals, the consequences of such a successful 
private-collective model of innovation could be far-reaching with regards to intellectual property rights, innovation 
policy and the development of knowledge- based industries. Open source software development may represent an 
important indicator of a post- industrial society where users develop knowledge and information- based products for 
their own needs and freely share them with others. Since users' rewards ensue from the production of the public 
good, in addition to the public good itself, we certainly know it is an interesting and perhaps new form of collective 
action. 
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Footnotes 

I. Selective Incentives derive their name from the way they are put to work: to target Individual, potential 
beneficiaries, encourage their contribution to the public good and punish their defection. 

II. In some cases, the production of knowledge can be central to the social movement's success For example, a 
movement attempting to Impose rigid governmental control of research In human genomics through lobbying 
might fund studies that closely Investigate the social and moral Implications of such research. For this, they 
might allocate a part of the monetary resources accumulated to research Institutes specializing In this type of 
studies. Eventually, society might benefit directly from the political actions of the social movement, but 
Indirectly also from knowledge diffusion. 

III. Michael Cusumano's seminal analysis of commercial software shows that software production evolves within 
certain parameters, such as product generations, financial resources, time lines and the capacity of developers. 
Flowever the process Is also fraught with uncertainty, frequent trials, rescheduling and so on ( Cusumano 1992) . 

Iv. Research has also uncovered various strategies for recruiting, that fit such a goal (see Benford 1993: Snow & 
Benford 1992 ) 

V. The option of free-rlding usually prevents the optimal supply of a public good from the outset by providing 
disincentives for the contributors. Free riders as such are of no harm since public goods are by definition non- 
rlvalrous In consumption. 

vl. Also spelled '/. effect' , this Is the phenomenon of a Website being virtually unreachable because too many 
people are hitting It after the site has been mentioned In an Interesting article on a popular news service like 
Slashdot.org , llnuxtodav.org , or freshmeat.net (adapted from I argon File 2002 ). 

vll. Peer-to-peer software leads to a type of network In which each workstation has equivalent capabilities and 

responsibilities. In contrast, the traditional network grounds on client/server software and architecture. In which 
some computers are dedicated to serve the others. Other peer-to-peer technologies Include Gnutella and 
Napster. Unlike Napster, Freenet does not require a central and operating server for file exchange. Freenet also 
handles file sharing by storing copies on local servers as the files travel backwards In the network towards the 
requesting node. This makes the technology more efficient than Gnutella, as when a certain type of Information 
gets requested often. It will be located In the vicinity of the requesting node. 

vlll. Lurker: One of the 'silent majority' In an electronic forum; who posts occasionally or not at all but Is known to 
read the group's postings regularly ( I argon File 2002; see also Nonnecke & Preece 2000) . 

lx. For example by Wired News with Ian Clarke published on October 29, 2002, or by BBC News published on 
March 12, 2001, or bv Cnet News on October 28, 2002 

X. A possible source of confusion may stem from the term resource as we use It. Whereas resources In resource 
mobilization theory denote the object of mobilization (knowledge, time, effort, labour), the communal resources 
refer to the potential, communally accessible benefit awaiting the actor who contributes to the collective action. 
In our case to the open source project. 

xl. patch: 1. n. A temporary addition to a piece of code, usually as a quick-and-dirty remedy to an existing bug or 
misfeature. A patch may or may not work and may or may not eventually be Incorporated permanently Into the 
program. 2. To Insert a patch Into a piece of code, ( larqon File 2002 ) 

xll. One should note, however, that Freenet being a public good would not exclude a potential third party 
downloading the software and then starting parallel development on her own. This phenomenon where 
somebody starts up a competing project using existing source code as a basis. Is known as forking. Forking has 
been observed In other Open Source projects, such as Open Source Unix ( Wavner 2000) , but we have not 
observed forking In the case of Freenet and we did not see any mention of a threat to fork Freenet. 
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xiii. A thread consists of a series of e-maiis (one maii pius the corresponding answers to it), normaiiy foiiowing the 
same maii heading. 
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